Implement to_d in Numeric and with the same number of arguments everywhere#423
Implement to_d in Numeric and with the same number of arguments everywhere#423fsateler wants to merge 1 commit intoruby:masterfrom
Conversation
fsateler
changed the title
…where This allows user code to be more generic, not having to care about the specific class. Preserve the BigDecimal override to allow returning the same object.
fsateler
force-pushed
the
feature/numeric-to-d
branch
from
f66b7dc to
7dbbe1d
Compare
|
Thank you for the pull request. However, I think we don't need to make Reason 1Ruby's core string.to_i(2) # OK
nil.to_i(2) # ArgumentError
float.to_i(2) # ArgumentErrorReason 2Even if rational.to_d(17) # OK
float.to_d(16) # OK
float.to_d(17) # ArgumentError(precision too large)
complex_with_float_real_part.to_d(20) # ArgumentErrorSo we still need to consider what is the receiver of
Reason3
# This is misleading, but can't change for backward compatibility
# Maybe we can add a deprecation warning someday, or fix to return 0.123e5
BigDecimal('12345', 3) #=> 0.12345e5
BigDecimal(12345, 3) #=> 0.12345e5
# Allowing this will add another misleading spec
'12345'.to_d(3) #=> 0.12345e5
12345.to_d(3) #=> 0.12345e5 |
2 participants
This allows user code to be more generic, not having to care
about the specific class.
Preserve the BigDecimal override to allow returning the same object.
--
This is a PoC PR. I don't know if this is desired. But my intuition would be that all Numeric types should be convertible to BigDecimal, with the same interface. What do you think?
Builds on top of #421 to avoid conflicts